Business case

2025-09-13

EDA

Chiamate suddivise per ora

Per ogni ora di ottobre ho contato il numero di chiamate in ingresso suddividendo per codifica

Analisi terzi di giornata

Non sembrerebbe presente una periodicità ogni 8 ore per tutte le codifiche, tuttavia potrebbe essere utile considerarla nel modello per coprire i casi in cui la componente parrebbe essere significativa (Mercato Libero Retail)

Analisi mezzi di giornata

Applicando la trasformazione \(\Delta_8 Y_t = Y_t - Y_{t - 8}\) si rimuove la periodicità con periodo di 8 ore, permettendoci di vedere più facilmente altre periodicità nei dati.

Anche in questo caso questa periodicità non sembra ugualmente diffusa tra tutte le codifiche, ma risulta utile includerla nel modello.

Analisi giornaliera

Applicando la stessa tecnica di prima, possiamo rimuovere le componenti periodiche con periodo di 12 ore.

Anche in questo caso risulta evidente una componente giornaliera.

Analisi settimanale

Analisi del trend

Rimuovendo anche la componente settimanale ci rimane da analizzare la presenza di un qualche trend.

Non risulta apparente la presenza di un trend. E’ rimasto solo rumore.

Conclusioni EDA

  • La portata dei flussi è sicuramente globalmente influenzata dalla codifica delle chiamate
  • Stagionalità osservate con periodo:
    • 8 ore
    • 12 ore
    • giornaliera
    • settimanale
  • La stagionalità a prima vista non sembrerebbe ugualmente diffusa, ma potrebbe essere presente con intensità proporzionale alla portata complessiva dei flussi della codifica, rendnedola più difficile da osservare nei gruppi con flussi globali inferiori.
  • Non risulta evidente la presenza di un trend

Formalizzazione modello

Componente deterministica

Proposta di modello per il flusso di chiamate: \[ \begin{align} \lambda(c, t) &= e^{q_c + \sum_{i=0}^4 a_i \cos(\omega_i t) + b_i \sin(\omega_i t)} \\ &= e^{q_c}e^{\sum_{i=0}^4 a_i \cos(\omega_i t) + b_i \sin(\omega_i t)} \end{align} \]

  • \(c\) rappresenta la codifica e \(q_c\) è quindi una costante additiva che dipende da \(c\). Regolano il flusso globale della codifica.
  • \(\omega_i = 2 \pi / T_i\) con \(T_i = 8, 12, 24, 168\) rispecchiando i periodi osservati durante l’EDA

Modello

Processo di Poisson non omogeneo con tasso \(\lambda(c, t)\): \[ x_t|c \sim PP(\lambda(c, t)) \]

Ciò implica che dato un intervallo temporale \((t_0, t_1)\) il numero \(Y_{t_0, t_1}\) di chiamate in ingresso segue la distribuzione:

\[ Y_{t_0, t_1}|c \sim \mathcal{P}(\Lambda(c, t_0, t_1)), \quad \Lambda(c, t_0, t_1) = \int_{t_0}^{t_1} \lambda(c, t) dt \]

Inoltre dato il tempo corrente \(s\) il tempo \(T|c, s\) per l’arrivo della prossima chiamata segue la distribuzione: \[ f(t|c, s) = \lambda(c, s + t) e^{-\Lambda(c, s, s + t)} \]

Approccio bayesiano: distribuzione a priori

Ho seguito un approccio bayesiano, pertanto ho posto una distribuzione a priori per tutti i parametri \(q_c, a_i, b_i\) da stimare nel modello. In particolare ho posto una distribuzione a priori normale di media \(0\) e varianza \(0.0784\). \[ q_c, a_i, b_i \sim \mathcal{N}(0, 0.0784) \]

Fitting del modello

Preprocessing dei dati

  • Il modo migliore per estrarre più informazione possibile dal dataset è quello di calcolare per ogni codifica il tempo che intercorre tra ogni chiamata in arrivo espresso in ore per comodità
  • Per non perdermi niente ho tenuto nel dataset anche il tempo tra l’ultima chiamata del 31 ottobre e la fine della giornata e ho aggiunto una colonna per tenermi traccia se il tempo registrato fosse censurato o meno
  • Ho dato a ciascuna codifica una sua colonna dedicata
  • Ho centrato il tempo espresso in ore in modo che avesse media 0
t y censored CR MT MLB MLR SI SIU T
−361.79 0.42 0 0 0 0 0 0 0 0
−361.79 0.02 0 0 0 0 1 0 0 0
−361.77 0.02 0 1 0 0 0 0 0 0
−361.77 0.02 0 0 0 0 1 0 0 0
−361.77 0.08 0 0 0 0 0 0 1 0
−361.75 0.05 0 0 0 0 1 0 0 0
−361.75 0.02 0 1 0 0 0 0 0 0
−361.74 0.05 0 1 0 0 0 0 0 0
−361.70 0.02 0 0 0 0 1 0 0 0
−361.69 0.03 0 0 0 1 0 0 0 0

Attenzione!

Purtroppo a causa di una svista durante l’analisi ho involontariamente ignorato i dati del CreditoBusinness. Fortunatamente costituiscono meno dell’1% dei dati e non dovrebbe aver impattato significativamente sulla corretta stima dei parametri. Non ho rieseguito l’analisi corretta a causa dei tempi particolarmente lunghi per l’esecuzione dell’algoritmo (6/7 ore)

Flusso medio per codifica

Ampiezza delle componenti stagionali

Previsione del flusso di ottobre

Performance

La previsione sembra seguire abbastanza bene l’andamento complessivo dei dati ma è ancora molto impreciso. Infatti i dati osservati finiscono all’interno dell’intervallo di confidenza al 95% solo il 76% dei casi. Ciò consiglia che il modello non è abbastanza flessibile da rappresentare adeguatamente l’andamento dei dati.

Come migliorare il modello

  • Rieseguire l’analisi includendo la codifica mancante
  • Analizzare separatamente e indipendentemente le diverse codifiche, in modo da avere le ampiezze delle componenti stagionali potenzialmente variabili tra le diverse codifiche
  • Aggiungere ulteriori componenti stagionali con frequenza più elevata
  • Condurre l’analisi basandosi sul numero di chiamate per ora invece che sui tempi intercorsi tra una telefonata e la successiva

Come sfruttare il modello

  1. Modellare il tempo di evazione tramite il campo Durata conversazione, differenziando potenzialmente l’analisi tra i diversi valori di GESTIONE.
  2. Sviluppare una funzione di perdita che tenga conto dell’impatto economico del personale e della perdita di clienti in base al numero di persone al centralino.
  3. Calcolare il numero di persone che minimizza la perfita media